1. Field of the Invention
The present invention pertains to the field of communicating between components in a computer system. More particularly, this invention pertains to the field of communicating via broadcast messages within a computer system.
2. Background of the Related Art
Broadcast messages are issued by a processor in a computer system in order to indicate to other components in the computer system that certain instructions have been executed or certain conditions have occurred internal to the processor. Broadcast messages are not directed or addressed to any particular system component or device, but are made available to the system as a whole. Broadcast messages are sometimes referred to as "special cycles." The messages are generally delivered by the processor to a bus controller which will then forward the message to a system bus, and therefore to any system devices attached to the system bus. Some examples of broadcast messages include "shutdown" or "halt" messages that indicate to the computer system that the processor is about to stop executing instructions. Another example of a broadcast message is a "flush" message that indicates to the computer system that internal processor memory caches have been invalidated and that external caches should also be invalidated in order to assure cache coherency.
Another example of a broadcast message is a "stop.sub.-- clock.sub.-- grant" message that the processor delivers in response to receiving a "stop.sub.-- clock#" signal from a power management device. (The symbol "#" following the name of a signal as used herein is an indication that the signal is considered to be asserted when it is in a low logic ("0") state.) The stop.sub.-- clock# signal indicates to the processor that the processor is to enter a low-power state which typically precludes the processor from executing instructions and from recognizing interrupts until stop.sub.-- clock# is deasserted. The stop.sub.-- clock.sub.-- grant broadcast message is issued by the processor in order to acknowledge that the processor received the stop.sub.-- clock# signal and to alert other devices in the system that the processor is preparing to cease instruction execution.
An example of a stop.sub.-- clock# and stop.sub.-- clock.sub.-- grant transaction is shown in FIG. 1. At time A, stop.sub.-- clock# is asserted, typically by a power management device. The processor responds to the assertion of stop.sub.-- clock# by issuing a stop.sub.-- clock.sub.-- grant broadcast message over a host bus which is generally received by a bus controller that then forwards the stop.sub.-- clock.sub.-- grant message on to a system bus. The stop.sub.-- clock.sub.-- grant message is delivered over the system bus by the bus controller at time B. The stop.sub.-- clock.sub.-- grant message is typically delivered over the system bus using multiple signal lines. For simplicity and clarity, the timing and logical state of the stop.sub.-- clock.sub.-- grant message is shown in FIG. 1 and in subsequent figures as if the message was delivered via a single signal line.
For computer systems with bus controllers and/or processors that do not support deferred reply transactions (deferred reply transactions are transactions that are scheduled to be completed after the completion of later issued transactions), a reply is communicated to the processor via a non-deferred.sub.-- reply.sub.-- ready# signal at time C. The assertion of the non-deferred.sub.-- reply.sub.-- ready# signal in general indicates to the processor that the previously issued transaction request (bus cycle) has completed. An example of a non-deferred.sub.-- reply.sub.-- ready# signal is the Burst Ready# (BRDY#) signal implemented on the Pentium.RTM. processor, made by Intel Corporation. Pentium.RTM. is a registered trademark of Intel Corporation.
In this particular example, the assertion of the non-deferred.sub.-- reply.sub.-- ready# signal indicates to the processor that the broadcast message has been delivered to the other devices in the system and that it is now permissible for the processor to cease execution of instructions. The amount of time elapsed between the delivery of the stop.sub.-- clock.sub.-- grant message at time B and the communication of the reply to the processor at time C is generally in the order of a several host bus clock periods.
After a period of time, it is possible that some event will occur that will stimulate the power management device to deassert stop.sub.-- clock#, which would allow the processor to restart the execution of instructions. Such an event may include, but is not limited to, communications network traffic or system input device activity. In FIG. 1, the stimulus event is depicted as occurring at time D, after which stop.sub.-- clock# is deasserted at time E. Once the condition that prompted the deassertion of stop.sub.-- clock# no longer exists, the power management device may reassert stop.sub.-- clock#, which is shown at time F.
A problem occurs for systems with bus controllers and processors that support deferred reply transactions. Because deferred reply transaction bus controllers have the ability to defer reply to the processor, it is possible that a deassertion of stop.sub.-- clock# may occur before the assertion of the deferred.sub.-- reply.sub.-- ready# signal. The deferred.sub.-- reply.sub.-- ready# signal is shown in FIG. 1 just below the non-deferred.sub.-- reply.sub.-- ready# signal in order to highlight the potential difference in signal timing. The deferred.sub.-- reply.sub.-- ready# signal, like the non-deferred.sub.-- reply.sub.-- ready# signal, indicates to the processor in general that a previously issued transaction request has completed. In this particular example, the deferred.sub.-- reply.sub.-- ready# signal indicates to the processor that the broadcast message has been delivered to the other devices in the system and that it is now permissible for the processor to cease execution of instructions.
The Pentium.RTM. Pro processor made by Intel Corporation is an example of a processor that supports deferred reply transactions. In the Pentium.RTM. Pro processor, the deferred.sub.-- reply.sub.-- ready# signal is implemented as several Response Status signals. For purposes of clarity, although a typical implementation of a deferred.sub.-- reply.sub.-- ready# may include several signal lines, the deferred.sub.-- reply.sub.-- ready# signal is represented herein as if it is implemented as a single signal line.
In the example of FIG. 1, the deferred.sub.-- reply.sub.-- ready# signal is shown as being asserted at time G. The deassertion of stop.sub.-- clock# before the processor receives the deferred.sub.-- reply.sub.-- ready# signal leaves open the possibility that the power management device may reassert stop.sub.-- clock# before the processor has seen the completion of the stop.sub.-- clock.sub.-- grant message as indicated by the assertion of the deferred.sub.-- reply.sub.-- ready# signal. This situation may confuse the processor, as it may think that the deferred.sub.-- reply.sub.-- ready# assertion indicating that the previous stop.sub.-- clock.sub.-- grant message transaction has completed is due to the later assertion of stop.sub.-- clock#. In other words, the processor effectively does not notice that there have been two assertions of stop.sub.-- clock#. Rather, the processor thinks that there has been only one assertion of stop.sub.-- clock# and that a response to that stop.sub.-- clock# has been issued via the stop.sub.-- clock.sub.-- grant broadcast message.
In this situation, the power management device is forever waiting for confirmation that the second stop.sub.-- clock# assertion has been recognized, and the processor, believing that it has already responded, is potentially forever waiting for the deassertion of stop.sub.-- clock#. Since the processor will not execute instructions or recognize interrupts until a deassertion of stop.sub.-- clock#, the computer system is effectively dead. Therefore, a method and apparatus for interlocking broadcast messages on a bus is desirable. The term "interlocking" as used herein is meant to include any device or method for preventing the situation where a system component takes action in response to a broadcast message issued by a processor before the processor receives communication that the broadcast message has been delivered.